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(54) System and method for controSing the use of a package of distrfeuted application software 



(57) A system for permitting only an authentic user 
to play a desired application contained in a distributed 
application package in one of predetermined operation, 
e.g., free play mode, charged mode, limit-attached play 
mode, etc The system comprises a client for playing an 
application under the control of a server connected with 
the dient through a communication network. The eppli* 
cation package (the volume) includes a cSstrfoution 
descriptor which contains mode codes assigned to the 
volume and the applications of the volume. The data of 
distribution descriptor is decided and stored h the 
descriptor at the time of distribution of the volume. This 
feature makes the system f lex&e. There is also dis- 
closed a system operatabte without cornmurocating with 
a server. 
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Description 

BACKGROUN D OF THE INVENTION 

1. Field of the Invention 

The invention generally relates to a security system and, more specifically, to a method and system for permitting 
an authentic user to use charged information which has been distributed via package or transmission media while 
charging and controlfing the use of distributed charged information. 

2. Description of the Prior Art 

In order to use charged information such as music, movies, games, etc. provided by information providers that pro- 
vide various programs of such charged information, a user has generally to take two steps, in the frst step (a obtaining 
step), the user obtains a desired program from one of the i n for mati on providers by purchasing a package media such 
as an FD (floppy disc), an optical disc (e.g.. CO-ROM (compact cfisc read only memory) and DVD (c&grtat versatile disc 
or video disc)), etc. on which the desired program is recorded (off-Sne distribution or obtaining) or by down loading the 
desired program from the server computer of an information provider through a predetermined procedure (on-line cfc- 
trfoubon or obtaining). In case of the on-line obtaining, the user may erfter play the program while obtaining it (i.e.. the 
two steps are executed in parallel) or store the program while obtaining it in the first step and execute the program tetter 
as the second step (or using step). In case of the off-line obtaining, in the second step the user loads the obtained 
recording mecfia into an appropriate device and directly plays (or executes) the program or once stores the program into 
the memory of the device and then plays the program. 

Japanese Patent unexamined publication No. H*7-295674 (1995) discloses a security system for use in the sec- 
ond or using step for a CD-ROM. in this system, the user can use encrypted information which is recorded togefter wfth 
a public key of atoll center (a center public key) on a CD-ROM by encrypting with the center pubQc key and sending a 
code of desired program Included in the information and a user-generated key to the riformatfon provider and by 
decrypting the information with an encryption key which has been encrypted with the user-generated key and sent by 
the information provider. However, the identity of the user is not verified, perrritting a mala fide user who have obtained 
other person's CD-ROM to use rt Further, the center public key is pressed together with the encrypted information on 
the CD-ROM. This rnakes K difficult to change the center public key. Also, this causes coherent providers who probably 
want to use different center public keys to force the CD-ROM manufacturer to use different masters (or stampers) in 
pressing the CD-ROMs. 

Japanese Patent unexamined publication No. Hei7-288519 (1995) discloses a security system for use in both the 
first and second steps. However, this 6ystem is only applicable to a system in which charged information is cSstrtuted 
online- 
Japanese Patent unexamined publication No. HeiS-54951 (1996) discloses a system in which the quantity of used 
softwaj-e is monitored, artf^ 

Since a dedicated hardware is necessary for irrpecSng of software use. this system is only surttJe for the use in a 
server in a on-line distribution system. 

There is also a system for permitting a user to use, only for a trial period, software which has been distributed with 
data defining the trial period. In this system, a mala fide user may make the software reusable by installing the software 
again or setting the user system clock for a past time. 

There are these and other proc/ams in the art. It ts an object of tie invention to provide a system for permitting only 
an authentic user (a user who have legally obtained charged information either on line or off line from an information 
provider) to use the charged Information without any (imitation, charging for each time of its use, or within the tolerance 
of a use-limiting factor (e.g.. the quantity used, the days elapsed since the day of its purchase or the current date) 
according to the type of the charged information. 

SUMMARY OF THE INVENTION 

Accorcfing to the principles of the invention, h is assumed that charged information or an application package is dis- 
tributed, either via package (or recording) media or via transmission media, together with at least control information 
such as a media title and a media code, etc. However, an illustrative embodiment witi be described mainly in conjunction 
with charged information recorded on and distrtouted by means of the DVD. 

For any type of charged information, charged information has been encrypted with a key and recorded on a DVD 
when obtained by a user. If distrfouted charged information to be played is of the IrmHJessly playable type, the charged 
information processing is achieved in the following way: the key is first obtained in a user public key-encrypted form from 
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the DVD on which the key has been recorded at the time of selling the DVD; the user pubic key-encrypted key is 
decrypted with a user secret key stored in a IC card into a decrypted key; and the encrypted charged information is 
decrypted with the decrypted key and consumed (that is. played or executed). The user-pub&c key-encrypted key may 
be obtained on tine from the server serving the client (device). 

5 ft cfistrtouted charged information to be played is of the usage-sensitive charging type, the user is charged for each 
time of using the information, tn this case, prior to processing the charged information, the dient cbubie-ercrypts and 
sends a user's credit card number to one of the to 11 servers of the provider of the information; the saver adds an 
amount (e.g.. piay time or duration) used associated with the rnfcnrafon tothe vatue in atotal arnourrt (software meter) 
field in a volume data table, and sends the updated total amount value to the client; and the cfient dspiays the updated 

10 total amount. Then the dient starts the charged information processing. 

If distributed charged information to be played is of the lirriUattached type, that is. the use of the information is to 
be limited by the toJerarce of a certain limiting factor concerning the Information consumption, then the dient is permit- 
ted to consume the charged information only if the use-timHing factor is within the preset Brnrt In case of this type of 
charged irttorrnatfon. prior to processing the charged information, the client sends the identifier (ID) code of a user spec- 

is ified appBcation which is recorded on the DVD to the server; on receiving the ID code the sever tests if the use-lrmiting 
factor associated with the user specified application is within the preset limit if not then the server informs the dent of 
the test result, and the dient displays the test result; if the test was successful, then the server updates the meter (or 
integrated value) of the use-limiting factor and sends the updated value to the dient; and in response to the reception 
of the updated value the dient displays the updated value. Then the d'iecH starts the charged information processing. 

so 

BRIEF DESCRIPTION OF THE DRAWING 

Further objects and advantages of the present invention wiH be apparent from the following description of me pre- 
ferred embodiments of the invention as illustrated in the accompanying drawings, tn the drawing, 

25 

FIG. 1 is a block diagram showing an arrangement of a system for permitting a user to use a rjstrfcuted application 

package on the terms of use of the package with a Nc^ security accortfng^ 

invention; 

FIG. 2 is a diagram showing an exemplary structure of an app&cation (or a charged information) package recorded 
30 on a DVD used in the inventive system; 

FIGs. 3 and 4 are dagrams showing, in a detailed form, exemplary data structures of the volume c^scnptor 22 and 
the distribution descriptor 23, respectively; 

FIG. 5 is a ftow chart of a volume control program for playing the applications) recorded on the DVD according to 
the prirxaple of the invention; 

ss FIG. 6A is a ciagram showing an exemplary structure of a volume data table stored in a server shown in FK3. 1; 
FIG. 6B tsa cSagram showing an exemplary structure of a appScatfon data table stored in a server 8; 
FIG. 7 is a cfiagram showing a structure of a server table 75 stored in the EEPROM 1 03 of toe dient 2; 
FIGs. 8A and 8B are flow charts of initial routines executed interactively by the cfient 2 and the server 8. respec- 
tively, at the beginning of the processes 650, 700 and 800. 

40 FIG. 9 is a flow chart showing a procedure of a free ptey process shown as step 650 in FIG. 5. wherein connecting 
adjacent blocks by two flow lines irx&cates that each block is executed imeractivery by a dient and an associated 
server; 

FIGs. 10A and 10B are flow charts jointly showing a procedure formed of exemplary expected play time Informing 
routines rrteractivety executed; 
45 FIGs. 1 1 A and 11 B are flow charts jointly showing a procedure formed of exemplary timed piay and metered usage 
report routines interactively executed for playing an application while timing the duration and displaying a timed play 
duration after the play; 

FIGs. 12A and 12B are flow charts jointly showing a procedure formed of exemplary timed application-play subrou- 
tines interactively executed for playing the application while timing the duration; 
so FIGs. l3Aand13B are flow charts jointly showing a procecfctfefomwdtf aftem^ 
tines interactively executed in which timing of play tirne is achieve 

FIG. 14 is a flow chart of an exemplary application play subroutine called tn steps 612 and 622 of FIGs. 12Aand 
13 A, respectively, and executed by the controller 100; 

FIG. 15 is a flow chart showing a procedure of a charged play process 700 shown as step 700 in FIG. 5. 
55 FIGs. 16A and 16B are flow charts jointly showing a procedure formed of exemplary expected charge informing 
routines interactively executed; 

FIGs. 1 7A and 1 7B are flow charts jointly showing a procedure formed of routines interactively executed in block 
650 of FIG. 15; 
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FIGs. 18A and 1 8B are flow charts joint*/ showing a procedure formed of exemplary timed play and metered charge 
report routines interactively executed for playing an application while timing the duration and displaying a charge 
and a total amount of charges after the play; 

FIG. 19 is a flow chart showing a procedure interactively executed by the dient 2 and the server 8 in tf>e operation 
btockSOOof FIG. 5, wherein blocks connected with two flow tines indicates that operation of the blocks is done by 
the two elements 2 and 8; 

FIGs. 20A and 20B are a key-encrypting key table and a users public key table, respectively, stored in the server; 
and 

FIG. 20C is a flow chart of a process tor obtaining the application encrypting key Ky from the server 8; 

FIG. 21 is a block diagram of an exemplary deapherer-fcuilHn 1C card IF according to the invention; 

FIG. 22 is a diagram showing a decoder used in place of the decoder 1 26 of FIG. 21 in a system 1 using the 

cryptosystem of FIG. 20C; 

FIG. 23 is a diagram for explaining the meanings of the terms-of-use (TOU) codes and the corresponding fimrt val- 
ues; 

FIG. 24 is a block diagram showing an arrangement of a system for playing a cfistrixrted application package on 
the terms of use of the package without cornnfujnicating with any server according to a second illustrative embodi- 
ment of the invention; 

FIG. 25 is a flow chart schematically showing an exemplary control program executed by the controller 1 00a shown 
in FIG. 24; 

FIGs. 26 and 27 are flow charts showing an operation of a free play mode shown in step 650a of FIG. 25 in a 
detailed form and a further detailed form, respectively; and 

FIG. 28 is a flow chart showing an operation of a firnrt-ettached play mode shown in step 800a of FIG. 25. 
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

For the sake of better urrierstancfing of the following description, it w3l be useful to c^ine some terms to be used. 

Charged information provided by an irrformatfon provider may be distributed off-line (m off-line cSstrfcufon) or on- 
line (in on-line cSstrtxttfon). In off-line distribution, the charged information is recorded on package mafia or recording 
media, and distributed through the sales network of the provider, that is. sold at stores in the sales network. The pack- 
age media include all sorts of portable recording media such as various types of magnetic discs, a variety of optical 
memory discs (e.g., CD. CD-ROM, DVD), and magnetic tapes and cartridges, to on-line cSstibutfon, the charged infor- 
mation is transmitted via transmission mecfia from the servers at the service points of the provider and the cfetributors 
aligned with the provider to the client device (e.g., PC (personal computer)) of the user who requested the charged 
information, and stored in a recording media of the client (device). The transmission media include any telecommuni- 
cation channels which permit data communication between the servers and the dent device. The package media and 
the transmission media are hereinafter referred to en bfoc as "distribution mecBa". 

The charged information may be any type of software such as music, movies, games, etc. which are each referred 
to as an "application - without discrimination. The distribution unit of charged information ts referred to as a "charged 
information package" or an "application package". There may be included one or more appficattons in an application 
package. 

The present invention relates to a system for permitting a user to useacSstrfeuted application package on the terms 
of use of the package with a higher security. 

Embodiment I 

For the purpose of simplicity, a first ifiustratrve embocfiment wiB be descrfoed in which package mecfia, among other 
things, DVDs are used as distribution media. 

FIG. 1 is a block diagram showing an arrangement of a system for permitting a user to use the applications) 
recorded on a DVD on the terms of use of the DVD with a higher security according to the first illustrative errtxxfiment 
of the invention. In FIG. 1, the system 1 comprises a client or DVD player 2 which plays a DVD 3, a telecomniunication 
network 4, and a server 8 at a toll center of the provider 6 which provides the application package of the DVD 3. 

FIG. 2 is a diagram showing an exemplary structure of an application (or a charged information) package 20 
recorded on the DVD 3 used in the inventive system 1. In FIG. 2, the application package 20 comprises at least one 
application 21, a volume (or package) descriptor 22 corrprising data concerning the application package 20. and a cfe- 
trtoutfon descriptor 23 comprising data which is determined mainly at the time of, e.g.. distribution or sales after the 
pressing of the DVD 3. (The volume descriptor 22 and the distribution descriptor 23 constitute s the volume control data 
of the volume 20.) In this embodiment it is assumed that a volume (or package) control program which controls the use 
of the application package 20 in cooperation with the server 8 is included in and distnouted with the application package 
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20. This, the application package 20 further comprises the package control program 24 suited for the terms of use of 
the package 20. The application® 21, the volume descriptor 22 and the package (or volume) control program 24 are 
recorded in the data area of the DVD 3 at the time of manufacturing the DVD 3, while the distrtjution descriptor 23 is 
recorded in the burst cutting area at the time of, e.g., sales of the DVD 3. 

s FfGs. 3 and 4 are diagrams showing, in a detailed form, exemplary data structures of the volume descriptor 22 and 
the distribution descriptor 23, respectively. In FIG. 3. the volume descriptor 22 at least contains a volume identifier 
(VID V ) 25 which the title of the application package 20 is probably used for and which is the same as the application 
identifier rf the package or volume 20 contains only one app&caton; a provider identifier 26; volume creation date and 
time 27 which may be used for the base point by which volume expiration data and time as descrtoed later is deter- 

w mined; and volume effective date and time 28 indicative of date and time until which the vofume 20 is available. If the 
volume 20 contains more than one applications, the volume descriptor 22 further contains app&cation identifiers 
(AID a 's)29. 

In FIG. 4, the distribution descriptor 23 comprises the fields of: a volume issue number (NO^ 30 which contains a 
serial number given to each of the distrfouted application packages of an identical volume identifier (volume ID or tide) 

is VID V in the order of distribution; a server public key (PKJ 31 the data of which is given by the server 6 at a toll center 
of the provider 6; a PK^ (user-public-key)-encrypted appHcatiort-encrypting key (K,) 32; and sates date and time 33. The 
key PKs 31 field contains a key which has been used in encrypting each app&cation 21 in the package 20 and which 
has been encrypted with a user public key (PKJ of the user who has legally obtained the package 20. Appropriate data 
are recorded in all of the fields 30 through 34 at the time of distribution of the package 20. Le.. at the time of sales of 

20 the DVD 3 in this embodiment. 

The distribution descriptor 23 further comprises the field 34 of terms-of-use code (mode code) plus limit value for 
the volume (the volume limit value field) and, for each of the application IDs 29, the fields 35 of terms-of-use code plus 
limit value for the application ID 29 (application Knit value field). If terms of use are set only to the volume 20, there is 
no need of the field 35. If terms of use are set to each application, the field is empty. 

26 FIG. 23 is a diagram for explaining the meanings of the terms-of-use (TOU) codes and the corresponding limit val- 
ues. In FIG. 23, the terms-of-use code may be, e.g., one byte in length. The higher digit (X) of the TOU code incScates 
the target to which the terms of use is applied as shown in table 36. That is, higher cfgits of 0, 1 , 2,... incScate fliat the 
TOU codes beginning with those digits are for the entire volume, application 1 , explication 2 and so on. Tne tower digit 
(Y) of the above mentioned terms-of-use code indicates the terms of use of the package 20 or the app&cation 21 to 

30 which the code is set, and is directly followed by a corresponding limit value as shown in table 37 of FIG. 23. Specif icaly, 
the terms-of-use code (or TOU code)of 00H means, for example, that the volume 20 is usable freety after cSstntxrtion. 
The value *31H* means, for example, that the application 3 to which the TOU code is set can be used by paying per unit 
of play duration. The lower digit of 2H or more means that the volume 20 or the application to which the TOU code is 
set can be used freely until the corresponding limit value are reached, which disables further use. As seen from the 

3s table, the use-iimrting factors determined by the TOU codes whose lower digits are 2H to 5H are the current date and 
time, the expiration date and time, the amount of used period, and the access count respectively. 

Since the data of the distribution descriptor 23 can be set as described above, this provides both the providers and 
the users with more flexibility than conventional system can provide 

Again in FIG. 1, the DVD player 2 comprises a controller 100 for corrtrofling the entire DVD player 2; data bus 102 

40 connected with the not-shown CPU (central processing unit), not-shown ROM (read-only memory). RAM (random 
access memory) 101, and EEPROM (electrically erasable programmable ROM) 103 included in the controller 100; 
human interfaces (IFs) 1 10 including input devices such as a keyboard, a voice recognition device, a mouse, a remote 
controller, etc.; an ICcaid interface (IF) 120 for connecting the bus 102 with the ROM (not shewn) in a IC card 5; a DVD 
driver 1 30 for reading out the data recorded on the DVD 3 and for demodulating and error-correcting the read data: a 

4s video and audio output IF 140 for receiving a MPEG 2 bit stream and ou$utting a video and audio output signals; a 
display device 146; a loudspeaker 1 48, and a communication IF 1 50 for communicating through the public telecomrnu- 
rtotfon network 4. The IC card 5 stores a user's password PWu and a user's secret key SKy which corresponds to the 
user's public key PK^ mentioned in conjunction with the PKy-enaypted AP-encrypting key (Ky) contained in the field 32 
of fie distribution descriptor 23 recorded in me burst cutting area of the DVD 3. The video and audio output IF 140 

eo includes a MPEG 2 video decoder 142 and a MPEG 2 audio decoder 1 44. 

As for obtaining the DVD 3, there may be some ways. If one is to buy a DVD 3, e.g., at some book store or through 
mail order, he or she has to have the PKu-encrypted version of an appficatfcn-encrypting key (KJ recorded in the burst 
cutting area of the desired DVD 3 by notifying his or her public key PKy which corresponds to his or her secret key SK^ 
stored in the IC card 5. If one is a member of a DVD distribution service, he or she can obtain a DVD with a PK^ 

55 encrypted AP-encrypting key recorded without notifying the PKy each time of obtaining because he or she must have 
notified the PKy when he or she applied for the service. 

In operation, the user first sets a desired DVD 3 in the DVD driver 1 30 of the DVD piayer 2, and issues a start com- 
mand to the DVD player 2 through an appropriate human IF 1 10. In response to a receipt of the start command, the 
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controller 100 reads the volume control program 24 from the data area of the DVD 3 through the DVD driver 130 white 
loading the read program 24 into the RAM 1 01 of the controller 1 00. and then executes the volume control program 24. 

FIG. 5 tea flow chart of the volume control program 24 for playing the application^) 21 recorded on the DVD 3 
according to the principle of the invention. In FK3. 5, the controller 100 first checks the AID1 field to see tf the volume 

s 20 contains a single application in step 500, tf not then the controller 100 displays the application IDs in the field 29 and 
prompts the user to select a desired one of the applications in step 502, and waits for the selection m step 504. If any 
application is selected in step 504, the controller 100 registers the application ID of the app&cation as the application to 
be played in step 506 and proceeds to step 508 to check the field 35 of the terms-of -use (TOU) code plus Imrt value tor 
the selected application to see H the field is empty. tf so, thecorrtrofier 100 proceeds to step 510 to read the volume limit 

10 field 34. 

On the other hand, if the test result is YES in step 500, then the controller 100 registers the volume ID as the appli- 
cation to be played in step 512, and reads the volume limit value 34 in step 510. 

tf the step 510 is completed or the test result of step 508 is NO, then the controller 100 checks the terms-of-use 
(TOU) code to see if the lower digit of the TOU code is 0 in step 514. tf so, then the oontroier 100 plays an application 
is free erf ctiarge in step 650. and othe^ in step 5 16. 

H so, the controller 100 plays an application in a usage-sensitive charging in step 700. and otherwise (if the lower c&git 
of the TOU code is 2 or more) play an application only when the software meter of a use^imiting factor is under apreset 
value in step 800. On completing any of the steps or processes 650 through 800, the controller 100 ends the program 
24. Thus, the DVD player 2 plays a program specified by the user according to the terms of use determined by the TOU 

20 code which has been set to either the application package or the specified application. 

The processes 650, 700 and 800 are executed interactively with an associated server a The servers 8 need vari- 
ous data for executing these processes, and store such data in the form of tables. 

FK3. 6A is a cSagam showing an exemplary structure of a volume data tabie stored in a server 8. In FIG.6A, Each 
of the records of the \/olurriec^ (VIDy) and issue No. (NO^ fields. The combination of 

ss VIDy and NO^ serves as the user ID of the user of the application package 20 or the DVD 3. For this reason, the table 
60 has, for the members or subscribers of DVD distribution service or the Ska, personal data fields which contains, for 
example, a member ID, a name, an adefress. etc. Each record further comprises a volume minute meter field (VM- 
METERyJ containing a software meter of play duration in minute which is attached to (or associated with) the volume 
20; a volume charge meter (VC-METER^ containing a software charge meter which is attached to the volume 20; a 

so limit value (LV V J containing a limit value associated with the TOU code (e.g.. the effective date and time, the allowable 
expiration date and time, the allowable access, etc.); a limit value meter (LV-METER^J; an application ID (AID^ field 
containing the title of the appfication; an application minute meter (AM-METER^ field containing a software meter of 
play duration in minute which is attached to the application of AJD^; an application charge meter (AC-METEIVu) 
field tor a software meter of play duration in minute which is attached to the application of AID^; a Imrt value (LV^J 

35 containing a limit value associated with the TOU code; and a limit value meter (LV-METER^i). 

FIG. 66 is a ciagram showing an exemplary structure of a application data table stored in a server 8. In FIG, 68, 
the application data table 70 comprises the fields of, for example, an application code (ACODEJ, an appfication title 
(AIDJ, a duration (D). a rate-per-access (RATE/ACCESS), an access count, a minute meter, etc. The duration is a 
period of time what it takes to play tfie application. The rate per access is a charge for a play of the whole appfication, 

40 which is used for informing the user of an expected play duration prior to a play. The rate per unit time is a charge for a 
unit time of play, which is used for the calculation of a charge for an actually timed play duration. The access count and 
minute meter fields contains the number of accesses to the application and a total amount of play time, which are not 
necessary for the present invention but will be used in statistical caJaJations for the analysis of, e.g.. the tastes. 
FIG. 7 is a diagram showing a structure of a server table 75 stored in the EEPROM 1 03 of the client 2. In FIG. 7, 

45 the fields of the table 75 comprises a server public key (PKJ % a server ID (SIDJ, a server network address (SADDJ, 
etc, this table 75 is used for associating the sever public key (PKJ contained in the cSstribution descrptor 23 recorded 
in the burst cutting area of the DVD with the ID and the network address. 

Play an Application Free of Charge 

60 

The initial routines of the processes 650, 700 and 800 are the same. 

FlGs. 8 A and 8B are flow charts of initial routines 60a and 80b which are executed irrteractrvef y by the client 2 and 
the server 8, respectively, at the beginning of the processes 650, 700 and 800. In FIG. 8. the controller 1 00 of the client 
ortheDVD2,in step 62, sends a service request with the network address CADD C of the cfierrt or DVD 2, the TOU code 
ss pJusfimit value, the volume ID (V!D V ), the issue number (NOyJ. the application ID (AID^a). and other data to the asso- 
ciated server 8 the ID of which is SID 8 (SID 9 is obtained from the table 75 in FIG. 7 by using the public key recorded on 
the DVD 3), and in step 92 waits for a response from the server (SIDJ 8. H there is a response from the server (SIDJ, 
the client 2 proceeds to the next step through a circle with "A" therein. 
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On the other hand, in FIG. 8B, the sever 8 of SID 6 receives the message from the client 2, that is, the service 
request and the accompanying data and stores date in a predetermined location for subsequent use in step 84. Then, 
the server 8 searches the table 60 for a record which contains VID* aid NCVi in the volume ID and issue No. fields 
thereof, respectively in step 86. If the search is unsuccessful, then the server 8 adds the record tor VIDy and NO^ and 

5 fits relevant fields with AtD v .^ and a limit value, rf any, in the tedble 60 in step 88, and proceeds to step 90. Also, if the 
search in step 86 is successful the server 9 proceeds to step 90 , where the server 8 selects a routine to execute next 
according to the value of the TOU code and enters the selected routine through a circle with *8* therein. In this case, if 
the TOU code « xOH (x: an arbitrary HEX number, the letter H in the last position indicates that the preceding number 
ts in hexadecimal), then a routine for playing an application free of charge is selected. If the TOU code > x1H, then a 

10 routine tor playing an application in usage-sensitive charging is selected. If the TOU code £ x2H, then a routine is 
selected which plays an explication only if the software meter of a use-limiting factor is under a preset value. 

FIG. 9 is a flow chart showing a procedure of a free play process shown as step 650 in FIG. 5, wherein connecting 
adjacent blocks by two flow lines incicates that each block is executed interactively by a ctient of CADD C and an asso- 
ciated server SID, as shown in detail later. If the TOU code is 0 in step 51 4 of FKx 5, then the server (CADD^ enters 

is the free play process 650 as shown in FIG. 9, and the client and the server (SID J execute the initial routine 80 in block 
660. In block 670. they executes an expected play time informing routine, that is, displays an expected play time before 
playing an specffied application. In block 680, they execute an application play and metered play time report routine. 
Since the routine 80 has been detailed in FIG. 8. the expected play time informing routine and the appfcation play and 
metered play time report routine will be detailed in the following. 

20 FIGs. 1 0A and 108 are flow charts jointly showing a procedure formed of exemplary expected play time inferrning 
routines 97a and 97b interactively executed by the client 2 and the associated server 8. respectively. In FKx 108. the 
server 8 retrieves the duration (DJ of the application of AID V ^ from toe table 70 in a weU known manner in step 91. In 
the next step 92. the server 8 calculates an expected total amount of play time accortfing to the value of the TOU code. 
Specifically, if the TOU code is OxH, thai the client adds the duration (DJ and the value of the VM-METER^j field of the 

26 record identified by VIDy and NKVi in the table 60. rf the TOU code is axH (a: the application number of the specified 
application in the volume), then the dent adds the duration (DJ and the value of the AM-METER^ field of the record 
kJenttied by VID^ NO^, and AID^ in the table 60. Then the server 8 sends the result to the cfient whose network 
address is CADD C in step 93, and ends the process. 

On the other hand in FIG. 10A, the cfient 2 receives the incoming message or the value of fre updated meter in 

so step 94. In the next step 95, the value is displayed as the total amount of usage. Then the client 2 ends the process. 

In updating a relevant meter, a predetermined value of duration has been used an the just described routines of FIG. 
10 (a preset value metering system). This arrangement is suited mainly for such applications as it takes a constant time 
to play, and wil not cause a problem unless the user discontinues the play. From this point of view, it is pretence to 
actuafly measure the playing time in metering (a timed value metering system). However, it is also noted that the preset 

35 value metering system is useful in informing the user of expected play time prior to an actual playing. 

FIGs. 1 1 A and 1 1 B are flow charts jotnUy showing a procedure formed of exemplary timed play and metered usage 
report routin es 675a and 675b i nteractivery executed by the client and the server, respectively, tor playing an application 
while timing the duration and splaying a timed play duration after the play. In the routine 675, the cfient and the server 
call a timed application -piay subroutine tor playing the application while timing the duration (play time) in step 200. 

40 Then the server 8 proceeds to step 210, where the client updates a relevant meter according to toe TOU code in 
the same manner as instep 92 of FIG. 10B. SpedficaMy.HtheTOUcocteisQ^ 

of the VM-METEfVi field of the record identified by VID V and NO^i in the table 60. If the TOU code is axH (a: the appG- 
cation number of the specified application in the volume), then the play time is added to the value of the AM-METErV 
^ field o* the record identified by VID^ NO v ^ and AID^ in the table 60. Then the server 8 sends the play time and the 
45 value of the updated meter (i.e., the total amount of play time) to the client whose network address is CADD C in step 
212, and ends the process. 

On the other hand, the client 2 r after step 200, make a test to see if there is a response from the server of SID S in 
step 21 4. This step is repeated until the client 2 receives a caH from the server 8. when the client 2 receives the incom- 
ing message or the value of the updated meter in step 216. In the next step 218, the client 2 cfisplays the play time and 

so the total amount of playtime, and then ends the routine 675. 

FIGs. 1 2A and 12B are flow charts jointly showing a procedure formed of exemplary timed appfication-play subrou- 
tines 205a and 205b executed by the client 2 and the server 8, respectively for playing the appBcatkxi while timing the 
duration. The server 8 of SID e waits for a notice in step 61 1 to see rf the dient has started playing the application. On 
the other hand, the client 2 of CADD C informs the server of a start of play in step 610 arxJ irnmeriatery call an application 

55 play subroutine in step 612. This, causes the server 8 to start a timer in step 613, and wate 

fromttecliert2instep615.0ncx>r^ the client informs the server 8 of the stop of play in step 614. 

In response to this notice, the server 8 stops and reads the timer as the play time in step 617. After steps 614 and 61 7, 
the client and the server return. 
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Though the above descrbed arrangement has used a timer of the server, rt may be possfcte to use a timer of the 
client. 

FIGs. 13A and 13B are flow charts jointly showing a procedure formed of alternative timed epptefovpJay subrou- 
tines 205ac and 203>c interactively executed by the client 2 and the server 8, respectively, in which timing of ptay time 
is achieved with a timer in the client In the alterative subroutine 205a. the client 2 starts a timer in step 620. calls an 
application play routine in step 622, stops the timer in step 624, sends the play time to the server 8 in step 626. and 
then returns. Chi the other hand, the server 8, on entering the subroutine 295b, wails for a call from the client of CADD C 
in step 621. tf there is a call from the client 2, then the server 8 receives the piay trme in step 623 and then returns. 

However, the arrangement of FIG. 13 has a posstoiWy of permitting a mala fde user to mandate the timer of the 
cBent2. From this point of view, the arrangement shown in FIG. 12 is preferable to that of FIG. 13. 

FIG. 14 is a flow chart of an exemplary application play subroutine called fci steps 612 and 622 of FIGs. 12Aand 
13 A. respectively, and executed by the controller 100. 

Prior to the description of the flow chen we define sorrie notatkxi c^ 
ing X with a key EK according to an encrypting algorithm e yields Y, then it is expressed as: 

6{EK.X)bY 

Sn^yifdecryptnTgYwrma algorithm d yields Z, then rt is expressed as: 

d(DK f Y) x Z. 

Assuming that the aigorithms e and d and the keys EK and DK correspond each other, that is, d(DK, Y) » X, rt follows 
that 

oXDK. e(EK. X))-X. 

Returning now to FIG. 14, the controller 100 read the PKy-encrypted appfccation-enoyptmg (AP-erKrypting) key 
(Kv) or elfPKy, tg from the f fled 32 of the distribution descriptor 23 of the DVD in step 602. Here, 

v«1,2 V, 

where V is the number of kinds of the application package. This iridkates that cSfterent appficatk)r>-enaypting keys K1 
through f^ is assigned to respective kinds of appScations, that is, volume VID1 through V\D r 

In the next step 604. the user secret key SKy is read from the JC card 5. In the next step 606. the PKy-encrypted 
AP-encrypting key el (PKu, K,) is decrypted with the user secret key SKu to obtain the application encrypting key 
Then in the next step 608, the rVenaypted application (AP), i.e., e(K^ AP) which is recorded on the DVD 3 is decrypted 
with the obtained AP-encrypting key f^, to obtain efK^ AP)) - AP . while passing the obtained application data 
to the video and audio output IF 140. The obtained app&cation data has the form of an MPEG 2 bit stream. The video 
and audio output IF 1 40 converts the MPEG 2 bit stream of the appfication data into video and aucfio output signals 
through MPEG 2 video and audio decoding. The video and audio ou^ut signals are apptied to the display device 146 
and the loudspeaker 148, respectively. 

Piay an Application in Usage-sensitive Charging system 

FIG. 1 5 is a flow chart showing a procedure of a charged piay process 700 shown as step 700 in FIG. 5. wherein 
connecting adjacent blocks by two flow lines indicates that each block is executed interactively by a cfient of CADD C and 
an associated server of SID 8 . In FIG. 15, the client 2 enters the process 700 via step 516 of FIG. 5 and proceeds to 
block 630. where the cfierrt 2 and the associated server 8 execute the initial routine 80. In the next block 640. the client 
2 displays an expected charge and a total amount of charges received from the server 8, and let the user decide 
whether to piay the desired application. 

FIGs. 16A and 16B are flow charts jointly showing a procedure formed of exemplary expected charge informing 
routines 640a and 640b interactively executed by the client 2 and the associated server 8. respectively The routines 
640a and 640b are very similar to the routine 97 except that in the routine 640. the DURATION (DJ or Talay time" has 
been replaced with RATE PER ACCESS and "charge"; between steps 92a and 93a, there has been added a step 641 
of the server generating and storing a pseuota rano^ nurrber R m a mem in step 93a. the server sends 

the pseudo random number R as weH; between steps 94 and 95a there has been added a step 643 of the client storing 
the received pseudo random number R in a memory location FT for subsequent use. The replacement of DURATION 
(DJ with RATE PER ACCESS is achieved by accessing a RATE PER ACCESS field 74 instead of a DURATION field 
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73 in table 70. Further, in the routine 640 there have been added the folowing steps: in step 644 following the step 96a, 
the client 2 makes a check to see if the user decides to piay the application; if not, the cSent 2 sends a quit message to 
the server of SA0D 6 in step 645, and ends the routine 640; on the other hand, in step 642 following the step 93a, the 
server 8 of SID e waits for a call from the client 2 of CADD C ; on receiving a call from the cfient the server makes another 
5 check in step 646 to see if what has been received is a quit message; if so, the dent ends the routine 640; and if the 
user decided to play the application in step 644. which means that what foe server has received is not a quit message 
but an encrypted credit card number as seen from the description below, then the client 2 and the server 8 proceed to 
the step 650 of FIG. 15. 

In the next block 650, the server 8 obtains a user's credit card number (CCNOu) through the client 2 keeping the 

to security of the card number as shown in FIGs. 1 7A and 1 7B. In step 647. the client 2 encrypts the crecft card number 
of the user which has been input by the user through a human IF 1 10 with a key, Le , the pseudo random number R 
which has been stored in a memory location FT in step 643 of FIG. 16A to obtain e2(R, CCNOu). In the next step 648, 
the client 2 further encrypts R + e2(R, CCNOu) with another key or a server public key read from the attribution 
descriptor 23 recorded in the burst cutting area of the DVD to obtain 

is elfPK^ R + e2(R, CCNOu)). 

In the next step 649. the client 2 sends the encrypted data to the server 6. Through step 646 of FIG. 168, foe server 
proceeds to step 650, where the server 8 finds that what was received from the client CADD C is encrypted data. In the 
next step 651 , the server 8 reads a server secret key SK^ from an IC card 7. in the next step, the server 8 decrypts the 
received encrypted data with the server secret key SK, as follows; 

20 6USK V encrypted data) * dlfSK^ elfPK., R + e2(R, CCNOu)) « R + e2(R, CCNOu). 

In step 653, the server 8 makes a check to see if the just obtained pseudo random number R coincides with the random 
number R which has been stored in a memory location R* of the server, if so, the server 8 sends an enable mess^e to 
the dent of CADD C , and in step 655 decrypts e2(R, CCNOu) with the pseudo random number R to obtain the user's 
credit card riurnber CCNOu. On the other hand, in response to a reception of the enable message in step 657, the dient 

25 2 exits from the process. After step 655. the server also exits from the process. If the result is NO in step 653, then the 
server 8 sends a disable message to foe client in step 656, and ends the process. In response to a reception of the dis- 
able message in step 657, then the cfient Displays a message to this effect in step 658, and then ends the process. 

After operation of block 650, the client 2 waits, in step 663, for a report from the server on whether the credit card 
for the transmitted card number (CCNOu) is valid or not while the server 8 refers to foe aedit company associated with 

30 the card number in step 661 to see if the credit card is valid, if not the server 8 informs the client 2 of the invalidity of 
the credit card in step 662, and ends the process. If the card is vafid in step 661. the server 8 informs the cfient of the 
validity in step 667. If foe client 2 receives a report from the server in step 663, the client makes another check in step 
664 to see if the report indicates the validrty of foe card, ft not the cfient display a message to inoicate the invalidty in 
step 665, and ends the process. If foe report rrxJicates the validity in step 664. wr^m 

55 then the client 2 and the server 8 proceed to the next block 670. 

Instep 670, the cfient 2 and the server 8 execute timed play and metered charge report routine. FIGs. 18A and 18B 
are flow charts jointly showing a procedure formed of routines 675ac and 675bc interactively executed for playing an 
application while timing foe duration and displaying a charge and a total amount of charges after the play. In FKx 18, 
the routines 675ac and 675bc are identical to foe routine 675a and 675b in FIGs. 1 1 A and 11B except that Time* has 

40 been replaced with "charge*, and accordingly VM-METER and AM -METER have been replaced with VC-METER and 
AC-METER 

The operation, in the dient 2. of playing an appfi cation on usage-sensitive charging is completed by block 675 of 
FKS. 15 or step 218a of FIG. 18 A. After step 212a, the server 8 charges foe play to the credit card number CCNOu 
obtained in step 655 of FIG. 17Btn step 680. This completes the whole of the chan^apryxatton play process of FIG. 
45 15. 

In this process, only information on charge is given to the user, ft is very easy to provide infor ma t i on on both time 
and charge by adding steps 91 through 93 and 95 to the routines 640b and 640a. and by adding stops 210 and 218 to 
the routines 6756c and 675ac 

As descnbed above, expected time andfor charge are (is) displayed before playing a user specified appfication. 
so This is helpful for foe user to decide whether to play the application. Additionally, charging is done based on foe actually 
timed piay duration. This makes foe charging reasonable. 

In foe above description, the arrangement is such that the user has to Input his or her credit card number CCNOu 
each time he or she wants to piay an application. However, instead of doing this, the credit card number CCNOu may 
be stored in non-volatile memory or EE PROM 103 in a PW u -encrypted form. In this case. CCNOu is obtained by 
ss decrypting PW u -encrypted CCNOu (e.g.. e(PW u , CCNOu)) with a password entered by the user. That is, d(entered 
password, e(PW u , CCNOu)) - CCNOu. 
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Permit the Play Within a Preset Limit 

FIG. 19 is a flow chart showing a procedure interactively executed by the client 2 aid the server 8 in the operation 
block 800 of Fia 5. wherein blocks connected with two flow lines indicates that operation of the blocks is done by the 
two elements 2 and 8. In this case, it is assumed that a preset limit is recorded in or on the application package and is 
transmitted from client 2 to server each time of play. On entering the process 800 via step 51 6 of FfG. 5. the client 2 
proceeds to step 801 , where the client 2 and the server 8 executes the initial routines 80. It is noted that in routine 80b, 
if there is a record for VID V and rKV h then the Rmrt value (LV^j) field of the table 60 of FIG. 6A contains the limit value 
transmitted from the cfient 2, otherwise, the received limit value is stored in the LV vW field when the record for VID V and 
NO V h ts added in step 88. 

Instep 810, the server 8 makes a if a meter 
the limit vatue. This check is made by comparing an LV field and LV-meter field associated with the TOU code in table 
60. if the value of the LV-meter is equal to or greater than the LV field value, then the server returns an over limit mas- 
sage to the dient 2 in step 820. If not, the server 8 returns an underiimit message to the client 2 in step 822, and pro- 
ceeds to step 828. rf the client 2 receives the overtimrt message in step 824. thenthecfient2c5spiaysan^ssao^tothis 
effect « not the dient 2 proceeds to the step 828. 

Since the expected play time informing routines 97a and 97b and the application play subroutine 600 has been 
descrtoed above, the description of steps 828 and 830 are omitted. 

According to this feature of the invention, it is posskie to fimit the use of charged information. This feature is espe- 
cially useful in case when a user who have paid in advance for the use of the application package is permitted to use 
the application package within a limit value. 

Though it has been assumed that the limit values are inducted in the application package, the limit values may be 
kept in the servers of the provider or distrtouter from the beginning. In this case, the limit values are fixed. However, if 
limit values are permitted to be set and recorded in the application package at the time of distrfcution or sales, the limit 
values are advantageously set according to an amount paid 

As is apparent from the foregoing, as a limit value, any use-limiting factors will do that can be measured in quantity. 
Such limit values are, for example, the effective date and time, the allowable expiration date and time, the maximum 
amount of play time, the aSowabfe access count 

ft is also possible to combine this feature with a charged application play feature. That is, an arrangement may be 
such that the user is permitted to use an application package on usage^ensitive charging only if the value of an LV- 
meter associated with the TOU is under the value of the conesponcfing LV or the value recorded m a field 33 or 34 of 
the distnbution descriptor 23. 

Modification I 

In the above ernboolment, applications, if more than one, in one volume are encrypted by an identical application 
encrypting key rV However, the applications APa in one volume may be encrypted with respective AP-^ncrypting keys 
Ka, where a lower case "a" following AP and K is a serial number assigned to each application ID. In this case, each of 
the AP-encrypting keys are encrypted with the user public key PK^ and stored in the Pr^-encrypted AP-encrypting 
key (K^ fields 32a in the distribution descriptor 23. 

Modification II 

It has been assumed that the user of the DVD 3 is limited to the purchaser thereof who have had the PKu^encrypted 
AP-encrypting key (KJ recorded on the DVD 3. However, the system may be so arranged that predetermined people, 
e.g., family members FM 1t FMg,..., FM N of the purchaser can use the DVD (N is the number of the tamfly members). 
One of trie ways to realize this is to encrypt the AP-encrypting key with a public key PK^ of each member F^i (n 
» 1. 2.....N) to obtain eKPK^, K,), elfPK^. KJ,..., elfPK^, and to record them in the PK^-encrypted AP- 
encrypting key e1 (PK^, KJ fields 32 of the distribution descriptor 23 at the time of purchase of the DVD. 

Modification III: Ky Retrieval From Server 

In the above description, the AP-encrypting key Ky has been recorded in a PK^ncrypted form on the DVD 3. How- 
ever, the AP-encrypting key may be managed by the server 8 and transmitted to the client or the DVD player 2 in 
response to a request issued from the DVD player 2 each time of use of the DVD 3. In this case, there ts no need of 
providing the distribution descriptor 23 with the Pr^-encrypted AP-encrypting key field 32. instead each of the servers 
has to store an AP-encrypting key table (or tabte) and a PKy table (shown in FIGs. 20A and 20B)m the hard disc. As 
shown in FIG. 20 A, the table a volume ID (VID V ) field (as the entry of record) and an AP-encrypting key (K,) field in 
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each record. In FIG. 20B, each record of the PKu table comprises a volume ID (VID V ) field (as the entry of record), a 
volume issue number (NOy.j) field andaPKy field (Successive same values in the first field are shown by showing only 
the first appearing one). Further, the process (or step) 610 of obtaining the AP-encrypting key that is, a group of the 
steps 602, 604 and 606 in the application play routine 600, has to be replaced with a process of FIG. 20C. 

s FIG. 20C is a f taw chart of a process in which the cfient DVD piayer 2 obtains the applkation ertcryptir^ 

the server 6. In step 616, the server 8 retrieves a key from the table by using VID^ In the next step 618. the key 
is encrypted with an arbitrary number used only in the current process, e.g., a pseudo random number R to obtain 
e2(R, KJ. In the next step 620, the server 8 retrieves a key PKufrom the PKutable by reat^ the PKuf^ of trw record 
which contains VID V and NCV, in the VID V and UO vA fields. respectively. In the next step 622, R + e2(R, K,) is encrypted 

io with the retrieved key PKu to obtain a double encrypted AP-encrypting key 
eKPKy. R + e2(R, KJ), 
which is returned to the cfiertwto^ the next step 624. 

On the other hand, the controller 100 of the client 2 waits for a response from the server 8 of SJD 8 in step 626. H 
there is any response from the server 8 of SID 6 in step 626, then the cfient DVD 3 receives the data e1 (PKy, R + e2(R, 

is Ky)) from the server 8 in step 628. In the next step 630, the received data is decrypted with the user seaet key SKy read 
from the tC card 5. Specifically, the following calculation is done. 

dlfSKu, eUPKu, R + e2(R, K,))) ~*> R + e2(R, 
In the next step 632, e2(R, KJ is decrypted with the obtained pseudo random number R. Specifically, the foSowing cal- 
culation is done. 

20 d2(R, e2(R, KJ) *=» 

Thereafter, the controSer 100 proceeds to the step 608 of FIG. 14. 

In this modification, the applications APa in one volume may be encrypted with respectfve AP-encrypting keys K*. 
In this case, the K, table has to be replaced with K« table in which each record comprises an application ID (AID J field 
and an AP-encrypting key (KJ field. Further in step 612, the controller 100 of the DVD player 2 has to also send the 

25 application ID of the appScafon to be played to the server. 

Also in this mocfficalion. the system may be, again, so arranged that predetermined people, e.g., fam8y members 

FM V FM 2 FMn ot the purchaser can use the DVD (N is the number of the family members). In this case, for each 

member FMn (n o 1 , 2 N). the server 8 has to use the member's own pub&c key PK^ in encrypting the AP-encrypt- 
ing key One way to realize this is to issue a volume issue number NO v+n to each mernber FMn at the time of saies 

30 of the DVD, provide the non-volaffle memory (not shown) of the DVD player 2 with a table for associating the user's 
password PWn with the volume issue number NCV^. send the volume issue number (NOuJ associated with the 
user's password in step 612. and use not the PKy table but a PK^ table in which each of records has the foBowing 
fields: 

Vir^NCWn. PIW 

3s Another way is to issue and record not only a volume issue number NOv„ ( but also family member numbers FMNn for 
all members at the time of sales of the DVD, provide the non-volatile memory (not shown) of the DVD player 2 with a 
table tor associating the user's password PWn with the corresponding tarrHty member number f^Nn, send the volume 
issue number (NO v _j) and the family member number FMNn associated with the users password in step 612. and use 
another PK^ table in which each of the records has the following fields: 
40 VID* NOvh. FMNn, PK^. 

In the process of FK3l 20C r the server 8 may be authenticated by means of a pub&c-key cryptosystern using a pair 
of server secret and public keys (SK,, PKJ. In this case, the server 8 signs the double-encrypted AP-encryp6ng key 
e1(PK u ,R + e2(R,K v )) 

with a signing key or the server secret key SK,, after step 622. White the cfient or DVD player 2 tests the signature by 
45 the server 8 with a test key or the server pubfic key PKg contained in the PK^ field 31 of the cfetnbution descriptor 23 

recorded in the burst cutting area of the DVD 2 before step 630. 

However, even rf just described authentication of the server 8 is omitted, an attacker wil never go to any greater 

length than a steal of TOU code plus limit value, a volume ID VID V a volume issue number NCVf, and the client network 

address CADD C . This is not a serious problem. 
so In the process of FKx 20C f a pseudo random number R has been used as a pseudo variable which takes a different 

value each time of execution of the process. However, as the pseudo variable, any thing wifidoif the resutt of encryption 

with it takes a different value each time of execution of the process. 

Modification IV 

55 

In the first illustrative embodiment, the decryption of application is achieved by software. For this purpose, the con- 
troller 1 00 has to read the user secret key SK^ from the IC card 5 through the bus 102, which leaves the possibility of 
permitting a breaker to easily steal the user secret key SKg through the bus 1 02. In order to prevent this, the process 
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achieved by the steps 604 through 608 may be realized by hardware as shown in FK3. 21 , which is a block Diagram of 
an exemplary decipherer-built-in IC card IF. In FIG. 21, the cKwpherer-bu&tnn IC card IF 120a comprises an IC card 
receptacle 121 and a printed wiring board 122 extorting from and fixed with the receptacle 121. An IC 123 is mounted 
on the printed wiring board 122. The IC 123 comprises a memory IF 125 which usually connects the rnemory of the IC 
$ card 5 with the bus 102 and, in response to an instruction from the controller 100, reads and passes trie key SKy to the 
naxtstageiaKydecxxJer^lbfr^^ elfPK^ KJ with the key SKu to yield K^; and an 

AP decoder 127 for receiving the key and encrypting e(K* AP) to yield application data (AP). The printed wiring 
board 122 portion may be preferably rnoldedtc^ 

a single body. By doing this, leaking of the user secret key SK^ can be prevented. 
jo This modification can be also appSed to a system 1 using the cryptosystem of FIG. 20C In this case, the 
decoder 126 of FIG. 21 has to be replaced with a ^decoder 126a as shown in FK3L 22. In FIG. 22, the K, decoder 
1 26a decrypts the input data, el (Pr^, R + e2(R, KJ), from the bus 1 02 by using the user secret key Sr^ passed by the 
memory IF 1 25 to obtain R + e2(R, K^), whHe decrypting the obtained data e2(R, KJ) with the obtained random number 
R and outputting the key Ky. 

15 

Embodiment 11 

FIG. 24 is a Nock diagram shewing an arrangement of a system capable of playing a distributed application pack- 
age. e.g.. a DVD on the terms of use of the DVD without communicating with any server according to a second inustra- 

20 trve errtoodiment of the invention, h FIG. 24, the system 1a is identical to the dient 2 of FIG. 1 except that the 
communication IF 150 has been elirnnaled because of m> need of cw 100 
has been replaced with a controller 100a. In the controSer 1 00a. a not-shown ROM for storing a control proc/ am as 
described later and the EEPROM 1 03 have been also replaced with a new ROM (not shown) and an EEPROM 1 03a 
In order to play a rote of the server 8. the system 1 a has to have table 60 of FK3. 6A in any non-volatle mwory. eg.. 

25 the EEPROM 103a and an application duration (play time) for each application as defined in table 70 of FIG. 6B has to 
be included m the control data of each appScation packaga 

FIG. 25 schematically shews an exemplary control program executed by the controller 100a shown in FIG. 24. The 
cxmtrol program of FI& 25 is also tdemical 

efimmated because the fimrt-attached play mode is not supported by the system 1 a in this embodiment and the steps 
90 650 and 800 are replaced with steps 650a and 800a. AaxxtSngfy. operation after ctep514w« be cfescrfced in the fol- 
lowing. 

rfthe lower cigit of the terrns-ofnise (TOU) code is 0 in the decision step 514, tr^ in step 650atr>eccfTtrofler 100a 
plays, k\ frie free play mode, the application stored in the selected application in step 506 or 512 and ends the operation. 
It should be noted that since the system 1a does not have the charged play mode, the lower dttft erf the TOU code is 
ss defined as follows. 



Higher digit of terms<rf- 
use code (Hexadecimal) 


Correspond kig imrt value 


Play mode 


0 


None 


Free play mode 


2 


Effective date and time 


Umit-atlached ptey mode 


3 


Allowable expiration date and time 


4 


Maximum amount of used period 


5 


Allowable access count 







Accordingly, rfthe lower digit of the TOU code is not 0 in thededsion step 514, then in step 800a the controfler 100a 
plays, in the limit-attached play mode, the application stored in the selected application in step 506 or 512 and ends the 
operation. 

FIGs. 26 and 27 show an operation of a free play mode shown in step 650a of FIG. 25 in a detailed form and a fur- 
ther detailed form, respectively. In FIG. 26, the controller 100a executes an initial routine 80a in step 660a, in step 670a 
executes an expected play time informing routine, and in step 680a executes an application play and metered play time 
report routine. 
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As shown in FIG. 27, in the initial routine 80c, the controller 100a searches the table 60 for a record which contains 
VID V and NO^ in the volume ID and issue No fields thereof, respectively in step 86. If the search is unsuccessful, then 
the controller 100a adds the record for VID V and NO v .j and fills relevant fields with AID^ and a limit value, if any, in the 
table 60 in step 68, and proceeds to step 90, Also, If the search in step 86 is successful, the server 9 proceeds to step 
s 90, where the controller 100a selects a routine to execute next according to the value of the TOU code and enters the 
selected routine. In this case, if the TOU code « xOH (x: an arbitrary HEX number, the tetter H in the last position irxfi- 
cates that the preceding number is in hexadecimal), then a routine for playing an application free of charge is selected. 
If the TOU code ^ xlH, then a routine is selected which plays an application only if the software meter of a use^imiting 
factor is under a preset value. 

io The expected ptay time informing routine 670a is identical to the routines 97 (FIG. 10) minus communication steps 
93 and 94, cornprising the above described steps 91, 92 and 95. SimSarty, it is seen from FIGs. 11 and 13A that the 
above described steps 620, 622. 624, 210 and 218 are executed in this order in the timed play and metered usage 
report routine 680a. In this way, the system 1 a permits the user to play the appficatfon stored in the selected application 
(steps 506 and 512 of FIG, 25) free of charge. 

15 FIG. 28 is a flow chart showing an operation of a limit-attached play mode shown in step 800a of FIG. 25. Since 
this operation is very similar to that of FIG. 1 9. only the flow is briefly described, omitting the details of each step. In FIG. 
28, controller 100a first makes a check if a meter associated with the TOU code has reached the Bmrl value obtained 
with the TOU code. If so, then the server returns an overtimrt massage to controller 100a in step 820. Otherwise, the 
contrdier 100a proceeds to the expected ptay time informing routine 828a (= 670a), where the controller 100a executes 

so the above desonbed steps 91 , 92 and 95, and then calls the application play subroutine 600 in step 830, thereby com- 
peting the operation. Since the appficatfon piay subroutine 600 has been detailed above, further description is omitted. 
In this way, the system la permits the user to play the ^plication stored in the selected appf icatfon (steps 506 and 512 
of FfG. 25) only if the limit value associated with the TOU code assigned to the volume or the user-specified application 
has not been reached. 

25 According to the second emtxxfiment the system 1a can operate in either of the free ptay mode and the limit- 
attached play mode without the need of communication with a server. For this, the system la may be made portable. 

Modifications 

so In the Bbave description, the illustrative ernbcriiment has been described m conjunction with the DVD. The same 

cBscussion can be applied to such package media as permit write once or mora 

Further, the present invention is also applicable to appScatfon packages efefrtouted via transmission media In this 

case, the distrbuted application packages are stored in a bufc storage in the user's device. An application package 

comprises one or more application and application control data that is. an application descriptor and distrfoutfon 
55 descnptor. One volume is stored as a file. Since a plurality of application package may be stored in a single storage, 

each application package does not have to contain a control program One control program, which may be distributed 

via either package or transmission mec5a, is enc*jgh for cmuserd^ 

packages are stored is set for a user specified one in the control program when the control program is installed. The 
data to be recorded in the dsinbutfon descriptor is inducted in the application package by the provider according to the 
40 information given by the user. 

As described above, one who is permitted to use an application package is ftmrted to an owner of the IC cajd which 
stores a user secret key SK^ corresponding to the user public key PK^ used tor encryption of the AP-encrypting key Ky 
in the application package. For this, even if someone has unjustly obtained an appficatfon package, for example, by cop- 
ying the whole volume from the DVD on which the volume is recorded, he or she can not use it without the IC card of 
45 the owner of the DVD. Thus the inventive system can prevent unjust use of an application package (DVD n this case) 
by any other person than the regular owner of the application package. 

Also, the inventive system is so arranged that most part of the application package is recorded by pressing in man- 
ufacturing process of the DVDs, whereas at least a part of the volume control data (i.e., the distribution descriptor) can 
be determined at the time of, e.g., distribution of each of the DVDs after the manufacturing process. This makes the sys- 
so tern flexible because control data can be easily changed without changing the stamper. 

In the initial routines 80a and 80b in FIG. 8A and 8B, the data transmitted with the service request may be 
encrypted in the same manner as in case of the transmission of user's crecfit card number shown in FIG. 17. However, 
in case of the initial routines, there are a plurality of data. These data may be encrypted in the following way. 
tf the data to be encrypted are D1 , D2,„. then they are first encrypted with a key R as fotiows: 
55 e2(R. D1), e2(R, 02),... 

Then further encryption is made with a server public key PK^as follows: 
elfPK* R + e2(R, D1) + e2(R, D2),....). 
In the process of FIG. 17, the user may be authenticated by means of a public-key cryptosystem using a pair of 
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user secret and public keys (SKu. PKJ. tn this case, the client 2 signs the dcxjble-encrypted crec&t card number 
e1(PK„FUe2(R, CCNOu)) 

with a signing key or the user secret key SK^ after step 648. While ttie server tests the signature by the client 2 with a 

test key or the user pubfcc key PKu before step 650. 
s Instead of storing a single server public key in the distrtoution descnptor 23, a plurality of server public keys or all 

the server public keys may be recorded. By doing this, it is possible, for example, to setting a difterentcha/r/edepencS^ 

on the server public key which the user have selected by appropriately corrtbming the tables 70 and 75. 

Also, application packages with an identical volume ID can have different server pubfic keys recorded. A plurality of 

toll center may be advantageously provided for application packages of the same title 
10 In order to prevent any use of IC card by other person than the owner of the IC card, it te poss&e to add. before 

the Sku reading step 604, the steps of prompting the user to enter a password through a human IF 1 10 and proceecSng 

to step 604 only if the entered password coincides with the user password PW U stored in the IC card. 

Though the IC card 5 is used in the above embodiment, the IC card IF 120 may be replaced with a magnetic card 

reader to permitting the use of the magnetic card. AHernativery, the arrangement may be such that the user enters his 
is or her password each time the user uses the DVD. 

Instead of storing the user secret key SKy in the fC card 5, the key Sku may be stored in run-volatile memory in a 

PW u -encrypted form. In this case, the toy SKy is obtained by decrypting PW u -encrypted SKu with a password entered 

by the user. 

The discussion of three preceding paragraphs are applied to the IC card used for storing the server secret key in 
20 the server. However, in this case the user has to be taken as the admmtstrator of the toll server. 

Many widely Different errtxriirrients of the present invention may be constructed without departing from the spirit 
and scope of the present invention. It should be understood that the present invention is not rmrted to the specific 
errtocdtrrtent described in the specification, except as defined in the appended ciaims- 

A system for permitting only an authentic user to play a desired arjpBcation contained hi a distrfculed application 
ss package in one of predetermined operation, e.g., free play mode, charged mode, reattached play mode, etc. The 
system comprises a client for playing an application under the control of a server connected with the cfient through a 
conroinication network. The application package (the volume) includes a cfetrfoution c^scriptor which contains mode 
codes assigned to the volume and the applications of the volume. The data of ofetribution descriptor is decided and 
stored hi the Descriptor at the time of dstribution of the volume. This feature makes the system ftexfofe. There « also 
so disclosed a system operatabi e without communicating with a server. 

Claims 

1. An application package for use in a system for playing an application contained in the application package (the vol- 
36 ume), the application package comprtsing: 

application data for at least one application; and 

volume control data for use in controlling said system, wherein said volume control data at least comprises: 
a volume ID for identifying the kind of said appKcation package (said volume); 
40 an issue number assigned in order of issue to each of the volumes of said kind; and 

application IDs each assigned to one of said at least one appfication contained in said volume, and wherein: 
at I east a part of said volume control data is to be added to said vol ume after the creation of said volume ; and 
said at least a part of said volume control data includes said issue number. 

45 2. An application package as defined tn clam 1, wherein: 

said application data has been encrypted with an encrypting key; and 

said at least a part of said volume control data includes a usei's public keywcrypted version of said encrypting 
key used. 

50 

X An application r*K*age as def^ 

codes which are assigned to said volume or said at least one app&caticn and each irx^ 
with one of said volume or said at least one arjpBcation to which the mode code is assigned. 

55 4. A package media on which an application package as defined in dawn 1 has been recorded. 

5. A package media of a write-once type on which an application package as defined in claim 1 has been recorded. 
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6. A package media on which an application package as defined in claim 1 has been recorded wherein said at least 
a part of said volume control data is recorded in an area different from data area where said appScatkn data is 
recorded on the package media. 

5 7. A method for sending data with a raised security from a first device to a second device through a public telecom- 
munication network, comprising the steps of: 

in said second device, 

10 generating a pseudo random number; 

transrrutting said pseudo random number to said first device; 

in said first device, 

75 encrypting said data with said transmitted pseudo random number into encrypted data; 

encrypting concatenated data consisting of said pseudo random number and said encrypted data with a 

public key of said second device into double-encrypted data; 

sending said double-encrypted data to said second device; in said second device, 

decrypting said double-encrypted data with a secret key of said second device which corresponds to said 
20 public key into decrypted data consisting of a decrypted random number portion and another decrypted 

portion; and 

decrypting said another decrypted portion wim 6aid ta^ 

6. A method for sending a plurality of pieces of data with a raised security from a first device to a second device 
25 through a public telecomrmjntcaton network, comprising the steps of: 

in said second device, 

generating a pseudo random number; 
so trartsmitting said pseudo random number to said first device; 

in said first device, 

encrypting each of said pieces of data with said transmitted pseudo random number into an encrypted 
35 piece of data; 

encrypting concatenated data consisting of said pseudo random number and said encrypted pieces of 

data with a public key of said second device into double-encrypted data; 

sending said ctouHe-encrypted data to said second device; in said second device. 

decrypting said dotWe-encrypted data with a secret key of said second device which corresponds to said 
40 public key into decrypted data consisting of a decrypted random number portion and said plurality of 

decrypted data portions; and 

decrypting each of said decrypted portions with said transmitted random rumt«r to obtain said pieces of 
data. 

45 9. A method as defined in dam 7 or 8. further comprising the steps, executed after said step of decrypting said clou- 
He-encrypted data, of: 

proceeding to a next step onty if said decrypted random number portion coincides with said transmitted pseudo 
random number; and 

so said second device informing said first device of a failure in decryption if said decrypted random number por- 

tion does not coincide with said transmitted pseudo random number. 

10. tn a system provided with means for playing an application contained in an application package, a method for per- 
mitting a user to play an encrypting key-encrypted application contained inaoSstnrxrted application package which 
55 further contains, as volume control data, a user's pubBc key-encrypted encrypting key so encrypted as to be able 
to be decrypted with a secret key of the user into said encrypting key, the method comprising the steps of: 

reading said user's public key-encrypted encrypting key from said distributed application package (said vol- 
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ume); 

obtaining said secret key; 

decrypting said user's public key-encrypted encrypting key with said secret key to obtain said encrypting key; 
and 

decrypting said encrypting key-encrypted application with said obtained encrypting key into application data 
while passing said application data to said means for playing an application. 

11. In a system comprising a client provided with means tor playing an application contained in an appftcation pactage 
and a server connected with the client through a csrrmmication network, a method for permitting a user to play 
one of encrypting key-encrypted applications contained in a distributed application package which further contains, 
as volume control data, a volume ID for identifying the kind of said dstrixited application package (said volume}* 
an issue number issued to each volume of the kind in an issued order and application IDs, the method comprising 
the steps of: 

said client reading said volume ID, said issue number and an application ID for said one of encrypting key- 
encrypted applications (said encrypting key-encrypted application) from said volume and sending to said 
server; 

in said server. 

retrieving said encrypting key by using said volume ID: 

retrieving a public key of said user by using said volume ID atxJ said issue r^ 

generating a pseudo random number; 

ctouble-encrypting said encrypting key with sad pseudo random number and said public key into a 
double encrypted data; 

sending said ctouWe-encrypted data to said client; in said client 
obtaining a secret key of said user which corresponds to said public key; 
obtaining said encrypting key by decrypting said ckxtte-encrypted data with said secret key; 
decrypting said encrypting 1^-erKrypted application with said obtained encrypting key into applica- 
tion data whie passing said application data to said means for playing an application. 

12. ArnetrtcdasdefiriedindaimlOo^^ 

said secret key from a portable memory of said user. 

13. A method as denned in claim 12, wherein said portable rnemory is an IC card. 

14. In a system comprising a client provided with means for playing an application package and a server connected 
withthedienttrtroughaco^ (the volume) con- 
taining, as volume control data, a volume ID and an issue number issued to each of the volumes of said volume ID 
in an issued order, a method for controlling the amount of play time ccsrprising the steps ot 

said client senrjng said volume ID and said issue number to said server; 

said server retrieving an expected play time associated with said volume I D and said issue number; and 
said server adding said expected ptey time to the value of a total play time associated with said volume ID and 
said issue number. 

15. In a system comprising a client provided with means for playing an application contained in an application package 
and a server connected with the client through a cortmirecation network for corrfroing the client the application 
package (the volume) containing, as volume control data, a volume ID, an issue number issued to each of the vol- 
umes of said volume ID in an issued order and an application ID for the application, a meftod tor controlling the 
amount of play time comprising the steps of: 

said client sencSng said volume ID, said issue number and said appftcation ID to said server; 
said server retrieving an expected play time associated with said volume ID, said issue number and said appli- 
cation ID; and 

said server adri ng said expected play time to the value of a total play time associated with said volume ID and 
said issue number. 
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16. In a system composing a client provided with means for playing an application contained in an application package 
and a server connected with the client through a communication network for oontroffing the cTterrt. the application 
package (the volume) containing, as volume control data, a volume ID and an issue number issued to each of the 
volumes of said volume ID in an issued order, a method for controlling the amount of play trme comprising the steps 

of: 

said client and said server interactively measuring, as a measured ptay time, a play time ol said application; 
and 

said server adding said measured play time to the value of a total play time associated with said volume ID end 
said issue number. 

17. A method as defined in claim 16. wherein said step of measuring a play time comprises the step of using a timer of 
said server. 

18. A method as defined in claim 16, wherein said step of measuring a play time comprises the step of using a timer of 
said client 

19. In a system comprising accent for playing an application package and a server connected with the client through 
a communication network wherein the application package (the volume) comprises application data and control 
data and at least a part of the control data has been added to the volume after the creation of said volume, a 
method for sending desired data from one side of said client and said server to the other side, the method compris- 
ing the steps of: 

including a secret key of said other side in said at lest a part of said control data: 

in said other side, 

generating a pseudo random number: 

transmitting said pseudo random number to said one side; 

in said one side, 

encrypting said desired data with said transmitted pseudo random number otto encrypted data; 
encrypting concatenated data consisting of said pseudo random rajmber and said encrypted data with 
said public key of said other side into ckxjbfe-encrypted data; 
sending said ctottte-encrypted data to said other side; 

in said ofter side, 

decrypting said double-enaypted data with a secret key of said other side which corresponds to said 
public key into decrypted data consisting of a decrypted random number portion and another 
decrypted portion; and 

decrypting said another decrypted portion with said transmitted random number to obtain said desired 
data. 

20. A method as defined an claim 19. wherein said generating a pseudo random number includes storing said pseudo 
random number in memory, and wherein the method further comprises the step, executed prior to said decrypting 
said another decrypted portion, of: 

in response to a determination that said decrypted random number portion does not coincide with said pseudo 
random number stored in said means for storing said pseudo random number stored in said rnemory, informing 
said one side of a faflure in decryption instead of passing the control to next means. 

21. In a system composing a client provided with means for playing an application contained in an application package 
and a server connected with the client through a communication network, a method for permitting a user to play an 
application contained in a dtstnbuted application package which further contains, as volume control data, a volume 
ID for identifying the kind of said distributed application package {said volume), an issue number issued to each vol- 
ume of the kind in an issued order, and an appfication ID for said application, the method comprising the steps of: 
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proceerJng to a next step only if the value of a meter field associated with said volume ID, said issue number 
and said application ID is under the value of a fimrt value field associated wrfri said volume ID, said issue 
number and said application ID in a volume data table; and 
displaying a message informing an overling on a dsplay device of sa^ 

22. In a system comprising a dient provided with mearo for playing an arjplicatto 
and a server <x>mected with the diem through a com 

application contained in a distributed application package which further contains, as volume control data, a volume 
ID for identifying the kind of said distributed application package (said volume), an issue rxmtwr issued to each vol- 
ume of the kind in an issued order, an application ID for said application and a limit value for Smiting the play of said 
application, the method comprising the steps of: 

proceeding to a next step only rt the value of a meter field associated with said volume ID, said issue number 
and sad application ID in a volume data table is under said limit value; and 
cfisplaying a message informing an overM 

23. A method as defined in daim21, wherein said limit value is one of effect 
and time, a maximum amount of play time, and an allowable access count 

24. A method as defined ri any of daims 11, 15 and 1 6 t wherein said step of said cfient sending to said server com- 
prises the steps of: 

said cfient encrypting at least one of said volume ID, said issue number and said application ID into encrypted 
data; and 

said server decrypting said encrypted data. 

25. A system for sending data with a raised security from a first device to a second device through a pubfic telecommu- 
nication network, comprising: 

means provided in said second device for generating a psaudo random number; 
means provided in said second device for transmitting said pseudo random number to said first device; 
means provided in said first device tor encrypting said data with said transmitted pseudo random number into 
an encrypted dato; 

means provided in said Irst device for errcrypting concatenated dato c^^ 

and said encrypted data with a pubfic key of said second aevice ifito dcxtte-erKrypted date; 

means provided in said first device for sending said double-encrypted data to said second device; 

means provided in said second device for decrypting sato double-erKrv^ 

ond device which corresponds to said public key into decrypted data consist^ 

portion and another decrypted portion; and 

means provided in said second device tor decrypting said another decrypted portion with said transmitted ran- 
dom number to obtain said data. 

26. A system for sending a plurality of pieces of data with a raised security from a first device to a second device 
through a pubfic teJewmrruriication network, comprising: 

means provided in said second device for generating a pseudo random number; 
means provided in said second device for transmitting said pseudo random number to said first device; 
means provided in said first device for encrypting each of said pieces of data with said transmitted pseudo ran- 
dom number into an encrypted piece of data; 
means provided in said first device for erca^ng concatenated dato 

and said encrypted pieces of data with a public key of said second device intodouble-encrypted date; 
means provided ^ said frrst device ^ 
means provided m said second de^ 

ond device which corresponds to said pub&c key into decrypted data consisting of a decrypted random number 

portion and said plurality of decrypted data portions; and 

means provided in said second device for decryptirig each of said decrypted portk^ 

dom number to obtain said pieces of data 
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27. A system as defined in claim 25 or 26. further comprising: 

means, provided in said seoond device, activated prior to decrypting each of said decrypted portions and 
responsive to a determination that said decrypted random number portion does not coincide with said trans- 
mitted pseudo random number, for informing said first device of a failure in decryption instead of passing the 
control to next means. 

28. A system for playing an encrypting key-encrypted application contained in a distributed application package which 
firmer contains, as volume control data, a users puttfc key-encrypted encrypting key so encrypted as to be able 
to be decrypted with a secret key of the user into said encrypting key, the system corrprising: 

means for reading said user's public key-encrypted encrypting key from said distributed qppfecabon package 
(said volume); 

means tor ob&ning said secret key; 

means for decrypting said user'6 public key-encrypted encrypting key with said secret key to obtain said 
encrypting key; 

means for decrypting said encrypting key-encrypted application with said obtained encrypting key to provide 
application data; and 

means for using said application data for playing. 

29. A system for permitting a user to play an encrypfirig key-encrypted 

package which further contains, as volume control data, a vohimeD for iderrtrfyir^ 

cation package (said volume}, an issue number issued to each volume of the kind tn an issued order and applica- 
tion IDs. the system comprising: 

a client for playing an appScation by using application date; and 

a server for controlling said client through a communication network, wherein said client comprises: 
means for reading and sending said volume ID, said issue number and an application ID for said one of 
encrypting key-encrypted applications (said encrypting key-encrypted application) from said volume to said 
server, said server comprises: 

means for retrieving said encrypting key by using said volume ID; 

means for retrieving a pufcrtc key of said user by using said votume ID and said issue number; 
means for generating a pseudo random number; 

means for double-encrypting said encrypting key wrth said pseuctorarKtomnunrfoerard said public tey into 
a double encrypted data; and 

means for sending said double-encrypted data to said client and said client comprises: 
means for obtaining a secret key of said user which corresponds to said public key; 
means for obtaining said encrypting key by decrypting said double-encrypted data with said secret key; 
means for decrypting said encrypting key-encrypted application with said obtained encrypting key to pro- 
vide application data; and 
means for using said appfication data for playing. 

30. A system as defined in daim 28 or 29, wherein said means for obtaining a secret key comprises means for reading 
said secret key from a portable memory of said user. 

31 . A system as defined in daim 30, wherein said portable memory is an IC card. 

32. A system for permitting a user to play a distributed application package which further contains, as volume control 
data, a volume ID tor identifying the kind of said distributed application package (said volume) and an issue number 
issued to each volume of the kind in an issued order, the system comprising: 

a client for playing said cistrfouted application package; and 

a server for controlling said dierrt through a communication network, wherein: 

said dierrt comprises means for sending said volume ID and said issue number to said server; and 

said server oomprises means for retrieving an expected play time associated with said volume ID and said 

issue number, and means for adding said expected play time to the value of a total play time associated with 

said volume ID and said issue number. 
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33. A system for permitting a user to play an application contained in a distributed appfication package which further 
contains, as volume control data, a volume ID for identifying the kind of said distrbuted appfication package (said 
volume), an issue number issued to each volume of the kind in an issued order and an application ©for the appli- 
cation, the system comprising: 

6 

a client for playing 6aid application; and 

a server for controlling said client through a communication network, wherein: 

said client comprises means for sending said volume ID, said issue number and sad application ID to said 
server; and 

" said server comprises means for retrieving an expected play time associated with said volume ID, said issue 

number and said application ID. and means for adding said expected retime to the vabe of a total play tone 
associated with said volume ID and said issue number, 

34. A system for r^nrtrtting a user to play an application contained in a distributed application package which further 
is contains, as volume control data* a volume ID for identifying the kind of said distributed application package (said 

volume), an issue number issued to each volume of the kind in an issued order and an application ID for the appli- 
cation, the system comprising: 

a client for playing said application; and 
20 a server for controlling said dient through a corrirwrtication network, wherein: 

sad client and said server comprise means for interactively measuring, as a measured playtime, a play time 
of said application; and 

said server further comprises means for adding said measured play time to the value of a total play time asso- 
ciated with said volume ID and said issue number. 

25 

35. A system as defined in claim 34, wherein said means for interactively measuring a piay time comprises means for 
using a timer of said server. 

36. A system as denned in claim 34, wherein said means for interactively measuring a ptay time comprises means for 
so using a timer of said client. 

37. A system for permitting a user to play an application package (the volume) cwnprising appfication data and control 
data wherein at least a part of the control data has been added to trie voluniean^tr» create 

system comprising: 

36 

a cfient for playing said volume; and 

a server for controlling said client through a cc>mmunicabon network, wherein said server comprises means tor 
storing a secret key of said server and said at least a part of said control data includes a public key correspond- 
ing to said secret key, and wherein the system comprises: 
40 means provided in said server for generating a pseudo random number; 

means for storing said pseudo random number; 

means provided in said server for transmitting said pseudo random number to said client; 

means provided in said client for encrypting desired data with said transmitted pseudo random number into 

encrypted data; 

45 means provided in said cfient tor encrypting concatenated data consisting of said pseudo random number and 

said encrypted data with said public key into ctajtte-encrypted date; 

means provided in said client for sending said ckxibte-encrypted data to said server; 

means provided in said server for decrypting said double-encrypted data with said secret key into decrypted 

data consisting of a decrypted random number portion and another decrypted portion; and 
so means provided in said server for decrypting said another decrypted portion with said transmitted random 

number to obtain said desired data. 

38. A system as defined in claim 37, further comprising: 

55 means, provided in said server, activated prior to said decrypting said another decrypted portion and resporv 

srve to a determination ttot said r^ 

number 6tored in said means for storing said pseudo random number, for inforrning said cbent of a failure in 
decryption instead of passing the control to next means. 
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39. A system tor permitting a user to play an application contained in a distributed application package which further 
contains, as volume control data, a volume ID for identifying the kind of said distributed application package (said 
volume), an issue number issued to each volume of the kind in an issued order and application IDs. the system 
comprising: 

5 

a client for playing an application by using application data; and 

a server for controlling said client through a communication network, wherein said client comprises: 
means for reading and sencSng said volume ID, said issue number and an application ID for said one of 
encrypting key-encrypted app&cations (said encrypting key-encrypted application) Irom said volume to said 
10 server, said server comprises: 

means for proceeding to next step only if the value of a meter field associated with said volume ID, said issue 
number and said application ID is under the value of a limit value field associated with sad volume ID, said 
issue number and said application ID in a volume data table; and 

means for causing said client to display a message informing an overt mit on a display device of said client and 
15 qurt the operation otherwise. 

40. A system for permitting a user to play an application contained in a distributed application package which further 
contains, as volume control data, a volume ID for identifying the kind of said cfstrfcuted application package (said 
volume), an issue number issued to each volume of the kind in an issued order, application IDs and Itrrvt values 

20 associated with respective appScatkxi IDs for limiting the play of respective applications, the system comprising: 

a client for playing an application by using application data: and 

a server for controlling said client through a communication network, wherein said dient comprises: 

means for reading and sending said votume ID. said issue nunt>er, an application ID for said one of encrypting 

25 key-encrypted applications (said encrypting key-encrypted application) and a limit value associated with said 

application ID from said volume to said server, and wherein said server comprises: 
means for proceeding to a next step only if the vaJue of a meter field associated with said volume ID, said issue 
number and said application ID in a volume data table is under said Emit value; and 
means for causing said client to display a message informing an overfimrt on a display device of sad dient and 

50 quit the operation otherwise. 

41 . A system as defined in daim 39, wherein said limit value is one of effective date and time, allowable expiration date 
and time, a maximum amount of play time, and an allowable access count 

35 42, A system as defined in any of claims 29. 33 and 34. wherein said means for sending to said server comprises 
means for encrypting at least one of said volume ID. said issue number and said application ID. 

43* A method for permitting an authentic user to play a desired one of the applications contained in a distributed appli- 
cation package in a system capable of playing an application, wherein said application package (said volume) con- 
40 tains volume control data inducing mode codes assigned to said volume and the applications of said volume, the 
method comprising the steps of: 

deciding to use one of predetermined play modes specified by one of said mode codes associated with said 
desired application; and 
45 playing said desired application in said specified pJay mode. 

44. A method as defined in daim 43. wherein the method further comprises the step of Inducing, in said mode codes, 
values indicative of a free play mode and at least one limit-attached play mode which correspond(s) to respective 
limit vafue(&) used for limiting usage. 

so 

45. A method as defined in daim 44, wherein said step of playing said desired application comprises the step of: 

in response to a determination that said one of said mode codes associated with said desired application 
includes a value indcatrve of said free play mode, simply playing said desired application. 

55 

46. A method as defined in daim 44, wherein said step of playing said desired application comprises the step of: 

in response to a determination that said one of said mode codes associated with the desired application 
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includes one of values indcative of said at least one limit-attached play mode, displaying a message to the 
effect that a limit value associated with said one of values has been reached instead of playing said desired 
application if said Gmrt value has been reached 

47. A method as defined in claim 43, wherein said volume control data further includes a volume ID, an issue number 
and an application ID for each of said applications, and wherein said step of decking to use one of predetermined 
play mod es comprises the steps of : 

obtaining said one of said mode codes associated with said desired application and corresponcfing limit value 
by using said application ID; and 

comparing said one of said mode codes with a meter value associated with said volume ID, said issue number 
and said application ID. 

48. A method as defined in claim 45, wherein each of said applications has been each encrypted with an encrypting 
Key and said volume control data includes a users public key-encrypted version of said encrypting key (a pubfic 
key-encrypted version encrypting key), and wherein said step of simply playing said desired application comprises 
the steps of: 

reeding said user's public key-encrypted encrypting key from said volume; 
obtaining a users secret key which corresponds to said users pubfic key; 

decrypting said users pubfic key-encrypted encrypting key with said user* seaetl^ to obton said encrypting 
key; and 

decrypting said desired qpp&catton with said obtained encrypting key. 

49. A system for permitting an authentic user to play a desired one of the applications contained in a distributed appli- 
cation package, wherein said application package (said volume) contains volume control data including mode 
codes assigned to said volume and the applications of said volume, the system comprising: 

means for deciding to use one of predetermined play modes specified by one of said mode codes associated 
with said desired application; and 

means for playing said desired application in said specified play mode. 

50. A system as defined in claim 49, wherein the system further comprises means for including, in said mode codes, 
values indicative of a free play mode and at least one limit-attached play mode which conespond(s) to respective 
Emit value(&) used for limiting usage. 

51. A system as defined in claim 50. wherein said means for playing said desired application comprises: 

means, responsive to a determination that said one of said mode codes associated with said desired applica- 
tion includes a value indicative of said free play mode, for simply playing said desired application. 

52. A system as defined in claim 50, wherein said means for playing said desired application comprises: 

means, responsive to a determination that said one of said mode codes associated with the desired application 
includes one of values indicative of said at least one limit-attached play mode, for cfispiaying a message to the 
effect that a limit value associated with said one of values has been reached instead of playing said desired 
application if said limit value has been reached. 

53. A system as defined in claim 49, wherein said volume control data further includes a volume ID, an issue number 
and an application ID for each of said applications, and wherein said means for deciding to use one of predeter- 
mined play modes comprises: 

means for obtaining said one of said mode codes associated with said desired application and corresponding 
Emit vahje by using said application ID; and 

means for comparing said one of said mode codes with a meter value associated with said volume ID, said 
issue number and said application ID. 

54. A system as defined in claim 51 , wherein each of said applications has been encrypted with an encrypting key and 
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said volume control data includes a user's public key-encrypted version of sad encrypting key (a public key- 
encrypted version encrypting key), and wherein said means tor simply playing said desired application comprises: 

means for reading said user's public key-encrypted encrypting key from said volume; 

means for obtaining a user's secret key which corresponds to said user's pubBckey: 

means for decrypting said user's public key-encrypted encrypting key with said user's secret key to obtain said 

encrypting key: and 

means for decrypting said desired application with said obtained encrypting key. 

55. A method for permitting an authentic user to ptey a desired one of the applications contained in a cfetrtouted appli- 
cation package in a system comprising a client capable of playing an appfication and a server connected with said 
client through a corrviiunication network, wherein sad application package (hereinafter referred to as "said vol- 
ume") contains volume control data including mode codes assigned to said volume and the applications of said vol- 
ume, the method comprising the steps of: 

said client deciding to use one of predeterrrttned play modes specified by one of said mode codes associated 
with said desired application; and 

playing said desired application in said specified play mode by means of cooperation between said client and 
said server. 

56. A method as defined in claim 55. wherein the method further comprises the step of including, in each of said mode 
ccxie. a value indicative of one of a free play mode, a charged play mode and at least one firtit-attached p!ay mode, 
wherein said volume control data further comprises a limit value associated with each of said at least one fimct- 
attached play mode. 

57. A method as defined in claim 55 or 56, wherein said volume control data further includes a volume ID, an issue 
number, and an application ID for each of said applications, and wherein said step of playing said desired applica- 
tion in said specified play mode includes an application play step of simply playing said specified Explication. 

58. A method as defined In claim 57, wherein each of said applications contained in a distributed appication package 
has been encrypted with an encrypting key and said volume control data includes a users pubfic key-encrypted 
version of said encrypting key (a public key-encrypted version encrypting key), and wherein said application play 
step comprising the steps of: 

reading said user's pubtic key-encrypted encrypting key from said volume; 
obtaining a user's secret key which corresponds to said user's public key; 

decrypting said user's public key-encrypted encrypting key with said user's secret key to obtain said encrypting 
key; and 

decrypting said desired app&cation with said obtained encrypting key. 

59. A method as defined in claim 57, wherein each of said applications contained in a distributed explication package . 
has been encrypted with an encrypting key and said volume control data includes a user's public key-encrypted 
version of said encrypting key (a public key-encrypted version encrypting key), and wherein said explication play 
step comprises the steps of: 

in said server, 

retrieving an encrypting key by using said volume ID; 

retrieving a user's public key associated with said volume ID and said issue number; 
a<xfcle-erK*ypting &akj encrypting key with a pseudo random riurnber and said user's public key into a dou- 
ble encrypted data; 

sending said double-encrypted data to said client; in said client 

obtaining a user's secret key which corresponds to said user's public key; 

obtaining sad encrypting key by decrypting said double-encrypted data with said user's secret key; 

decrypting said desired application with said obtained encrypting key. 

60. A method as defined in claim 57, wherein said step of playing said desired application further comprises the steps, 
executed prior to said application ptay step, of: 
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said server retrieving an expected play time associated with said desired application: and 
displaying said expected play time on a display device of sad client 

61 . A method as defined in claim 57. wherein said step of playing said desired application further comprises the steps 
of: 

measuring, as a measured ptay time, a duration of said application play step; 

adding said measured play time to a play time meter associated with said mode code to obtain a totaJ amount 
of piay time: and 

displaying said measured play time and said total amount of play time on a o5spiay device of said client after 
said application ptay step 

62. A method as defined in damn 61, wherein said step of measuring a duration comprises the step of measuring said 
play time by using a timer of said server. 

63. A method as defined in claim 61 . wherein said step of measuring a duration comprises the step of measuring said 
play time using a timer of said dient 

64. A method as defined in darn 57, wherein said step of deciding to use one of predetermined play modes comprises 
deciding to use said charged ptay mode if said one of said mode codes associated with said desired application 
indudes a value rncficative of said charged play mode, and wherein said step of playing said desired application 
comprises the steps of : 

saiddient obtaining and sending a credit cad number of said user to said server: 
proceeding to a next step only if the credit card of said number is found to be vafid from a reference to an asso- 
ciated crecft company; 

displaying, on a display device of said client, a charge for play decided based on a measurement of a duration 
of said application play step and a total amount of piay charges after said eppfcatton play step; and 
said server charging said play to said credit card number. 

65. A method as defined in claim 64, wherein said step of playing said desired appftcatjon further comprises the steps, 
prior to said application play step, of: 

displaying, prior to said application play step, an expected charge and an expected total amount of charges on 
said display device; and 

letting the user decide whether to play said desired application. 

66. A method as defined in dakn 64, wherein said steo 
user to said server comprises the steps of: 

in said server, 

generating a pseudo random number; 

storing said pseudo random number in memory: 

transmitting said pseudo random number to said dient; 

in saiddient 

prompting said user to input said credit card number; 

dc^e-encrypting said crecfit card number first with said transmitted random number and then with a 
severs public key included in said volume control data into a obubie-ercrypted number; 
sending said double-encrypted number to said server; in said server, 

decrypting said double-encrypted number with a server's secret key into a decrypted random number and 
another decrypted data; and 

decrypting said another decrypted data with said transmitted random number to obtain said credit card 
number. 

67. A method as defined in claim 66, wherein said step of said dient obtaining and sending a credit card number of said 
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user to said server further comprises the steps, executed prior to said step of decrypting said another encrypted 
data, of: 

proceering to a next step only rf said decrypted random number coincides with said pseudo random number 
s which has been stored in said memory; and 

displaying a message informing a failure in decryption and quitting the operation otherwise. 

68. A method as defined in claim 57 wherein said step of deciding to use one of predetermined ptay modes comprises 
deciding to use one of said at least one imtt-attached play mode if said one of said mode codes associated with 

10 said desired application includes a value indicative of said one of said at least one Hmrt-attached play mode, and 
wherein said step of playing said desired application comprises the step of: 

in response to a determination that a meter value associated with said one of said rnxte codes associated with 
said desired appfi cation in a record identified by said volume ID, said issue number and an application ID of 
75 said desired application in a volume data table has reached a limit value associated with said mode code, cfs- 

piaying a message informing an overfimit on a display device of said client instead of executing said application 
play step. 

69. A method as defined in claim 68, wherein said fimrt value is one of effective date and time, aflowabie expiration date 
20 and time, a maxirnum amount of play time, and an allowable access count 

70. A system for playing a cSstributed application package in one of predetermined ptay modes in concert with a server, 
wherein the application package contains a data set encrypted with an encrypting key (a K-encrypted data set) for 
each of at least one application and volume control data for use in contro&ng operation of toe system and the 

ss server and the volume control data includes mode codes defining said play modes, toe system comprising: 

means for permitting a user to select one of said at least one application of said volume; 
means for deciding to use one of said predetermined ptay modes associated with one of said mode codes 
assigned to said selected application; and 
30 means for playing said selected appication in said selected play mode in concert wiih said server. 

71 . A system as defined in claim 70, wherein each of said mode codes includes one of values for a free play mode, a 
charged play mode and at feast one limit-attached play mode. 

& 72. A system as defined in claim 70, wherein said voJume control data further includes a volume ID, an issue number 
and an application ID for each of said applications, and wherein said means for playing said selected application in 
said selected play mode at least comprises: 

means for setting said server for said selected play mode by sending to said server said volume ID, said issue 
40 number, and the application ID and said mode code associated with said selected appfication; and 

application play means for simply playing said specified application. 

73. A system as defined in claim 72. wherein said volume control data further includes a user's public Key-encrypted 
encrypting key, and wherein said application play means comprises: 

45 

means for reading said user's public key-encrypted encrypting key from said volume: 

means for obtaining a user's secret key which corresponds to said user's public key; 

means for decrypting said user's public key-encrypted encrypting key with said user's secret key to obtain said 

encrypting key; and 

so means for decrypting the K-encrypted data set of said selected application with said obtained encrypting key 

74. A system as defined in claim 73, wherein means for decrypting said user's pubfic key-encrypted encrypting key and 
said means for decrypting the K-encrypted data set are realized as an integrated circuit 

55 75. A system as defined in claim 72, wherein said application play means comprises: 

means for receiving double-encrypted data from said server; 

means for obtaining a user's secret key which corresponds to said user's public key; 
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means for obtaining said encrypting key by decrypting said double-encrypted data with said user's secret key; 
and 

means for decrypting the K-encrypted data set of said selected appfication with said obtained encrypting key. 

76. A system as defined in claim 75. wherein means for obtaining said encrypting key and said means for decrypting 
the K-encrypted data set are realized as an integrated circuit 

77. A system as defined in ctaim 74 or 76, wherein said integrated circuit is incorporated into said means for obtaining 
a user's secret key. 

78. A system as defined in daim 73, wherein said means for deciding to use one comprises means for deciding to use 
a free play mode and wherein said means for playing said selected application further comprises: means, prior to 
said application play means, of: 

means for receiving data from said server; and 

displaying said data as an expected play time for said selected application. 

79. A system as defined in claim 73, wherein said means for deciding to use one of said predetermined play modes 
comprises means for deciding to use a free p&y mode, and wherein said means for playing said selected eppfea- 
tion further comprises: 

means for causing said server to obtain, as a measured piay time, data of a operation period of said application 
play means; 

means for receiving first and second data from said server; and 

means for c&spfaying, just after the completion of operation by said application play means, said fast and sec- 
ond data as said measured play time and a total amount of play time, data as said measured play 6me and a 
total amount of play time. 

80. A system as defined in claim 79, wherein said means for causing said server to obtain data of said operation period 
composes means for informing said server of the start and the end of operation by said appficaSon play means to 
utilize a timer of said server. 

81. A system as defined in claim 79, wherein said means for causeig said server to obtam data of a operation period 
comprises: 

means for measuring said operation period of said application play means; and 

means for sending said operation period to said server for use in a calculation of said total amount of play tame. 

82. A system as defined in claim 72, wherein said means for deciding to use one comprises means for deciding to use 
a charged play mode and wherein said means for playing said selected application further comprises: 

means for obtaining and sending a credit card number of said user to said server; 

means responsive to a verification result of said credit card from said server for starting a next process only rf 
said result is positive; and 

means for displaying a charge tor play decided based on a measured play time of said application play means 
and a total amount of play charges after operation of said application play means. 

83. A system as defined in daim 82, wherein said means for playing said selected application further comprises: 

means activated prior to operation of said application play means for displaying an expected charge and an 
expected total amount of charges and letting the user decide whether to play said selected application. 

84. A system as defined in claim 82, wherein said volume control data of said distributed application package further 
includes a sevens public key. and wherein said means for obtaining and sending a credrt card number of said user 
to said server comprises: 

means for prompting said user to irput said credit card number; 
means for receiving a random number from said server; 
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means for obtaining said server's public key from said volume; 

means for (kxible-encrypting said ae* 

ptEbfk: key into a douWe-encrypted data; 

sending said double-encrypted number to said server; 

85. A 6ystem as defined in dahn 84, wherein said means for said client obtaining and sending a credit card number of 
said user to said server further comprises: 

means responsive to a positive result of random number check from said server for starting a next process; and 
means responsrve to a negative result of said random number check from said server for displaying a message 
indicative of a failure in said random number check and quitting the operation for sab selected appficatioa 

86. A system as defined in claim 72, wherein: 

said means for deciding to use one comprises means for deciding to use a limrt-atiached play mode: and 
said sending to said server includes sending a limit value associated with said mode code, and wherein said 
means for playing said selected application further comprises: 

means operative poor to operation of said application play means for receiving from said server a limit check 
result indicative of whether a limit value associated with said mode code has been reached; and 
means responsrve to an ever limit case of said result for starting a next operation. 

87. A system as defined in claim 66, wherein said limit vaiue is one of effective date and time, afiowabie expiration date 
and time, a maximum amount of play time, and an allowable access count 

88. A system for controfiing through a ccmrnunication network a client device to play a cfistributed application package 
in one of predetermined play modes, wherein the application package contains a data set encrypted with an 
encrypting key (a K-encrypted data set) for each of at least one application and volume control data for use in con- 
trolling operation of the system and the client and the volume control data includes a volume ©. an issue number, 
an application ID for each of said appficattons, and a mode code for said volume or mode codes for said applica- 
tions, the system comprising: 

volume data table for storing, for each volume, said volume ID, said issue number, said mode code for said vol- 
ume, and said application ID and said mode code for each of said appticatons; 

means for receiving a service request a vokime ID, an issue number, an appScation ID and a mode code and 
other data from said client; 

means for storing said received application ID, said received mode code and other data m appropriate fields of 
a record identified by said volume ID and said issue number; 

means responsive to a determination that there is no record identified by said volume ID and said issue number 
in said volume data table for adefing said record in said volume data table and storing said received application 
ID and mode code and said other data in relevant ftetds of said record; and 

means operative on the basis of said received mode code for deciding to subsequently passing the control to 
means for supporting a play mode associated said received mode code. 

89. A system as defined in claim 88, wherein said means for supporting a play mode at least comprises means for sup- 
porting application play means, of client, for simply playing an application identified by said received application ID, 
and wherein said means for supporting said application play means of said client comprises: 

first means for associating a given volume ID with a corresponding encrypting key; 

second means for associating both a given volume ID and issue number with a corresponding user's public 

key; 

means for retrieving an encrypting key associated with said received volume ID from said first means; 
means for retrieving a user's public key associated with said received volume ID aid issue number from said 
second means; 

means for double-encrypting said encrypting key with a pseudo random number and said users public key into 

a double encrypted data; and 

sending said c*>uWe-encrypted data to said client 

90. A system as defined in claim 89, further comprising an application data table for storing data for each kind of appli- 
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cation, wherein said received mode code defines a free play mode, and wherein said means for supporting a play 
mode associated said received mode code comprises: 

means, activated prior to an operation of said means for supporting application play means of said dient, for 
retrieving an exported ptay time associated with said received application ID from said application data table; 
and 

means for sending said expected play time to said dient 

91. A system as defined in claim 89, wherein said received mode code defines a free ptay mode, and wherein said 
means tor supporting a play mode associated said received mode code comprises: 

means for measuring, as a measured play time, a duration of application play: 

means for adding said measured play time to a play time meter associated with said received mode code in 

said volume data table to obtain a total amount of play time; and 

means for sending said measured play time and said total amount of play time to said dient. 

92. A system as defined in darn 91, wherein said means for measuring a duration comprises: 

means responsive to a notice of the start of operation by said application play means of sad cSent for starting 
a timer; and 

means responsive to a notice of the end of said operation tor stopping said timer. 

93. A system as defined in daim 91, wherein said means for measuring a duration comprises: 

means for receiving a measured duration from said dient. 

94. A system as defined in claim 88. wherein said received mode code defines a charged play mode, and wherein said 
means for supporting a play mode associated said received mode code comprises: 

means for receiving a credit card number of said user from said server ; 

means, responsive to a determination, from a verification of said credfc card number, that said credit card 
number is not vaSd, for informing said dient of invalidity and quitting the operation of said means for supporting 
a play mode; 

means, responsive to a determination, from said verification of said crecfit card number, that said credit card 
number is valid, for informing said cfient of a validrty and proceeding to a next operation; and 
means for charging said play to said credit card number. 

95. A system as defined in claim 94, wherein said means tor supporting a play mode associated said received mode 
code further comprises: 

means activated prior to operation of said application play means of said client for retrieving an expected 
charge from said application data table by using said received application ID; 

means for calculating a sum of said expected charge and a value of a charge meter associated with said 
received volume ID or application 10 depending on said received mode code; 

means operative prior to operation of said application ptay means for sending said expected charge and said 
sum to said dient; and 

means responsive to a receipt of a message of quitting for quitting said means for supporting a play mode. 

96. A system as defined in daim 94, wherein said means for receiving a crecfit card number of said user from said 
server comprises: 

means for generating a pseudo random number; 
means for storing said pseudo random number in memory; 
means for trarismrtting said pseudo random number to said dient; 
means for waiting for a double^ncrypted data from said client; 
means for obtaining a servers secret key; 

means for decrypting said double-encrypted number with said server's secret key into a decrypted random 
number and another decrypted data; and 
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means for decrypting said another encrypted data with said transmitted random number to obtain said credit 
card number. 

97. A system as defined in daim 96, wherein said means for obtaining a user's secret Key comprises means tor reading 
5 said user's secret key from a portable memory of said user. 

98. A system as defined in ciaim 96. wherein said means for receiving a crecfit card number of said user from said 
server further comprises: 

io means responsive to a deterrrination, mate prior to said decrypting said another, that said decrypted random 

number coincides with said pseudo randcmnurnber which has b^ 
He message to said client and proceeding to a next operation; and 

means responsive to a determination, made prior to said decrypting said another, that said decrypted random 
number does not coi ncid e with said ps eudo random number which has been stored 'm said memory tor sending 
75 a disable message to said ctient and quitting said supporting a play mode. 

99. A system as defined in claim 88. wherein: 

said received mode code defines a limit-attached play mode; and 
so means lor receiving a service request further receives a limit value associated with said mode code, and 

wherein said means for supporting a play mode associated said received mode code comprises: 
means for proceeding to a next operation only H the value of a software meter associated with said mode code 
in said volume data table is under said fimrt value; and 

means for sencfing a message informing an over limit to said dent and quitting toe operation of said means for 
25 supporting a play mode associated said received mode code if the value of a software meter associated with 

said mode code in said volume data table is not under said limit value. 

1 00. A system as defined in daim 99, wherein said limit value ts one of effective date and time, allowable expiration date 
and time, a maximum amount of play time, and an allowable access count 

30 

101 -A system as defined in any of claims 54, 73 and 75, wherein sax* means for obtaining a user's secret key comprises 
means for reading said user's secret key from a portable memory of said user. 

1 02.A system as defined in ciaim 28 or 29. wherein said means for obtaining said secret key comprises means for read- 
as ing said user's secret key from a portable memory of said user. 

H&A method as defined in any of claims 10. 1 1 , 19, 21. 22 and 55, wherein said application package is recorded on a 
package media. 

40 104.A method as defined in claim 103, wherein said package media is of a write-once type, and sad dient is a system 
capable of playing said package media of said write-once type, 

105.An application package as defined in clam 1, wherern said package metfa fe distributed to a purchaser thereof or 
a subscriber thereof via a transmission media, 

45 

106-A system as defined in any of claims 28, 29, 37, 39, 40, 70 and 88. wherein said application package is recorded 
on a package mecfia. 

107. A system as d^ined in daim 106, wherein said application package is recorded on a package media of a write- 
so once type. 

108. A system as denned in claim 106, wherein at least a part of said volume control data is recorded, after manufac- 
turing said package mecfia, in an area different from a data area where said at least one application is recorded. 

ss 109.A system as defined in claim 108, wherein said dient is a system provided with means for playing said package 
media of said write-once type. 

1 10.A system as defined in any of claims 28, 29. 37, 39. 40. 70 and 88. wherein said application package is recorded 
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on a DVD and at least a part of said volume control data ts recorded, after manufacturing said package media, in a 
BCA (buret cutting area) of the DVD, and wherein said client is a system provided with means for playing said DVD. 

111^metrKrt as defined in any of ciaims 10, 11, 19, 21 , 22, 43 and 55, wherein the application package has been dis- 
tributed to a purchaser thereof or a subscrtoer via a transmission media and at least a part of said volume control 
data has been added to said application package after preparing said application package. 

112.A system as defined in any of ciaims 28, 29, 37, 39, 40, 49, 70 and 88. wherein said application package has been 
distributed to a purchaser thereof or a subscriber thereof via a transmission mecfa and at least a part of said vol- 
ume control data has been added to said application package after preparing said appScstkxi package 
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